1. Field of the Invention
The present invention relates to a method for determining operational characteristics of a program.
It applies notably validation of applications relative to given specific operational criteria and, in particular, to the automation of the control of the program in order to execute it on target platforms by given users.
The invention likewise relates to a system implementing the method according to the invention to guarantee that applications proposed by a server observe validity criteria associated with platforms for executing these applications.
2. Description of the Prior Art
The majority of small onboard systems (payment terminals, electronic organisers, mobile telephones, smart cards, etc.), manufactured some years ago were closed systems capable of executing only determined programs installed at manufacture. Similarly, although functionally more open, the majority of computers were disconnected from any network and the few programs they did execute originated from well-identified software editors.
Due to this slight variability, it was possible to “contain” the operating faults of the execution platforms and programs.
Today, the trend is to open small onboard systems: even if control does not always return directly to the end user, new programs may in the future be loaded onto these execution platforms. Further, many computers and onboard systems are connected, temporarily or not, to networks (Internet, mobile telephony, etc.) on which programs of often unknown origin and often indeterminated functionality are downloaded. Finally, segmentation of markets and the multiplication of suppliers, hardware models and software versions result in combinations of configurations not always anticipated, despite the definition of standards. This situation accentuates the risks of malfunctioning, notably with respect to security and interoperability.
Voluntary or involuntary, the malfunctions of an application primarily concern security. An application may for example execute illicit operations (disclose secret code, connect to unauthorised sites, silently send messages, etc.), execute licit operations but for which it has no appropriate rights, consume more resources than it may be entitled to and thus disqualify other applications, alter precious data, etc.
Another major problem concerns interoperability. In fact, an application may require hardware or software functionalities which prove not to be present on the execution platform (for example because they are optional or limited) or which are present unexpectedly (for example due to version incompatibility). In this case, the application does not run or functions poorly, which the end user may wrongly attribute to the supplier of the service or equipment.
The consequences of these malfunctions may be very serious in the case of critical systems where security is vital. This is the case for example for applications in the banking, health, transport, identity domains, etc. Even when the malfunctions are minor for the users and only end up as slight damage or system outages, the commercial repercussions may be disastrous for the suppliers of hardware or software: not only may this necessitate costly hardware recalls, but it especially may damage their reputation among consumers. The risk is notably evident for telephone operators who allow their users to download new programs to their mobile phones.
Other than the problems of security and interoperability, certain suppliers also want to apply deontology discipline (for example, for the control of access to minors), principles of ergonomics or style rules (for example, complying with a “Look and Feel”).
The problem is in fact more generally that of controlling the adequacy of a program for a certain “policy” of security, interoperability, etc.
Before responding to the question of controlling programs, a first step consists of establishing criteria, first of all, which define whether it is acceptable or not that a given program be executed on a given target platform (or a set of platforms) by certain groups of given users. Security criteria may notably originate from a previous risk analysis, which notably evaluates the assets to be protected on the platform and in the programs, the threats to these assets, and the measures to be taken to guard against them. Interoperability criteria may be drawn from error cases signalled by test teams and the users, as well as from good programming experience by developers.
For example, in the case of application to smart cards, a security criterion may stipulate that it is prohibited to use excessively weak “DES” keys, for example of a length of less than 128 bits. Similarly, an interoperability criterion may stipulate not to use “RSA” key, or “RSA” keys longer than 1024 bits, because the target platform does not handle this type of key, or keys of such a size.
To be verified non-ambiguously, the criteria must be clearly formulated. A criterion is often expressed in the form of constraints concerning the usage of routines or classes of libraries. In the case of “Java Card” applications (specialised language for execution on a smart card), the security criterion example hereinabove is expressed more explicitly by: “The buildKey(keyType,keyLength, . . . )” “method is not called with a “keyLength” argument less than 128 if the “keyType” argument is equal to the value of the constant “TYPE DES””.
(“Java” and “Java Card” are registered trade marks of Sun Microsystems. For legibility reasons, the prefix of the javacard.framework.KeyBuilder class will deliberately be omitted).
Therefore the following program meets the security criterion:
“void install (byte[ ] buf, short ofs, short len) {...switch (buf[ofs++]) {  case 1://Use DES 128 bits   myKey = buildKey (TYPE_DES, LENGTH_DES3_2KEY);   break;  case 2://Use DES 192 bits   myKey = buildKey (TYPE_DES, LENGTH_DES3_3KEY);   break;  case 3://Use RSA 1024 bits   myKey = buildKey   (TYPE_RSA_PRIVATE,LENGTH_RSA_1024);   break;   }   ...   }
In fact, irrespective of the execution paths, the “buildKey” method is always called with arguments compatible with the criterion: or else “keyType” is “TYPE DES” and “keyLength” is “LENGTH_DES3—2KEY” (equal to 128) or “LENGTH_DES3—3KEY” (equal to 196), or else “keyType” is “TYPE_RSA_PRIVATE” (different to “TYPE DES”).
On the other hand, the following program does not meet the criterion.
void install (byte[ ] buf, short ofs, short len) {...myKey = buildKey(buf[ofs++], buf[ofs++]);...}
In fact, the value “but” is a dynamic argument: it is therefore possible to construct keys of arbitrary type and length. In particular, it is therefore possible for “buf[ofs]” to be equal to “TYPE_DES” and for “buf[ofs+1]” to be less than 128.
With respect to effective control of a program, the state of the art may be summarised as follows:
Several approaches are employed today to determine whether a given program meets given criteria for a given platform. They are distinguished according to several aspects: control is static (prior to execution on the platform) or dynamic (during execution); control is black box (without examining the code) or “white box” (examining the code); control is “manual” (without the aid of analysis tools) or automatic (with the aid of an analysis tool). Controls currently being used are the following:                The criteria, notably security, may be applied by dynamic controls carried out during execution of the program. This approach has three major disadvantages. First of all, it discovers the problems too late, once the program is already loaded and executing. Next, because it has only one black box vision of the application, it needs to arbitrarily limit exploitation of the functionalities and resources of the platform (for example, not sending any more than three messages). Finally, it does not solve the interoperability problems.        The program may also be tested in black box, without regarding the code. With this approach, the program is executed under a certain number of supposedly representative circumstances, and its performance is observed from the outside to assess whether it observes the criteria. This solution may respond to certain questions related to ergonomics, but does not provide a strong guarantee on the questions of security or interoperability. In fact, with this method only a small number of possible execution paths are examined, even though there is an infinite number of them. For example, Trojan horses (program or data which seem harmless when loaded on the platform but which then facilitate an attack, for example by a pirate or a virus) cannot be detected definitely.        The program may be controlled manually, by examining the code but without the aid of an analysis tool. This solution has numerous disadvantages. Such control is in fact long (therefore costly) and fastidious, in practice prohibiting the processing of large volumes of programs. In addition, it is necessary to repay the cost of the control with each new version of the program, the execution platform or criteria. Furthermore, this approach supposes in practice that the source code of the program is available, which is less often the case for reasons of confidentiality or intellectual property. When only the object code is available, manual analysis becomes extremely long and difficult, and the risk of human error is multiplied accordingly.        The program may also be controlled automatically, with the aid of an analysis tool. Several types of tool exist today:        Certain tools verify by means of static analysis that the code of a program complies with general rules of good formation and good typing, which affords certain guarantees of good operation, irrespective of the target platform. This is for example the case of “bytecode verifiers” associated with Java execution environments, including Java Card. Such analysers of types may operate just as well on the source code as on the object code. However, they do not meet particular criteria, for example relating to security or interoperability.        Other tools, especially intended for developers, verify by means of static analysis that the code of a program cannot conduct operations which have no meaning, such as dereferencing a null pointer or acceding to an array element outside the limits. These tools therefore contribute certain guarantees for proper operation, irrespective of the target platform. But as for type analysers, they do not meet particular criteria.        Finally, certain tools examine the program source or object code, to search for occurrences of routine calls. They therefore apply specific criteria which prohibit the use of certain routines (whether for reasons of security or interoperability): they reject any program which comprises calls to these routines. However, such tools cannot either verify the kind of rule given as an example hereinabove: it is necessary to not only detect that the buildKey method is called but also to know if its first argument is equal to “TYPE_DES” and its second argument is less than 128.        